This invention relates to management of a computer application. In particular it relates to the optimization of a computer application which is written for more than one platform.
Some computer programs require different instruction sequences on different hardware, or different versions of the operating system. For example, on the Intel x86 range of processors a program may need to update a memory location in an atomic fashion. If the machine has a single microprocessor, then the instruction inc [counter] will read the memory location xe2x80x98counterxe2x80x99, add one to the value retrieved, and store the result back into the memory location. As all this occurs in one machine instruction, the program cannot be interrupted during this operation, so another thread of program execution could not update the location at the same time. On a multiprocessor machine, another processor could read the memory location after the first processor has done the read, but before it has done the write. If the second processor is also attempting to increment a value at the memory location then an increment will be lost. To prevent this happening, the Intel instruction set provides the lock prefix, which prevents a second processor from accessing the memory location until the read-modify-write instruction is complete. The lock prefix (lock inc [counter]) could be used on a single processor machine, but there is a performance disadvantage, as the prefix may result in the memory cache system being bypassed. There is therefore a need to selectively include the lock prefix on single processor machines.
Previously different versions of the software for each environment need to be shipped. This can double the size of the shipped program code, and provide maintenance complexities as when a new or fixed version is shipped it must be built for all the different environments.
Another disadvantage is that any patches to the application must be applied at run time. This requires the code to be in a writable piece of memory, which could allow the program code to be corrupted accidentally or maliciously. However some operating systems or processors do not allow writable code memory, or make it complex. E.g. Intel x86 processors have executable, and possibly readable code segments, but not writable code segments. The code segment would need to be aliased by a writable data segment for the code to be patched.
It is possible to use a subroutine for the operation but this adds a call and return overhead to the instruction.
A method of resolving a program code module in a computer platform, said method comprising: loading a module into memory; locating operation code within the module; selecting a patch for the operation code; and modifying the operation code with the patch.
The operating system uses the dynamic module loader to patch operational code into an application to optimise the application for that operating system and platform. It reduces the need to create a different application for each platform and operating system combination. The operation code is pointed to by a module header fix up location pointer. The above solution causes the code to be patched at load time and advantageously by the operating system itself. All the application program has to do is to ensure that the appropriate DLL exporting the right instruction sequence is installed. Additional benefits are that the code remains non-writable and cannot be corrupted, and there is no call-return overhead. Furthermore there is faster execution, in the single processor example, the only overhead is one nop instruction.
Each module may contain more than one operation code location for modifying. Each fix up location may contain the same or different operation codes and may respectively relate to the same or different patches. Such relationship between the operational code and the patch is defined in a header.
The fix up operation code may be located in the module by looking up fix up references in a table within the module header. The same header may indicate the name of the patch to be used.
The platform has an operating system which may contain at least one patch for a fix up operation code. The patches may be preloaded into the operating system and remain there semi permanently or may be preloaded with initialisation of the application. Alternatively the patches may be loaded on demand from the same source as the application.
The patch may be superimposed over the fix up operation code by directly loading into that memory location.
Advantageously the patch may be exported from a dynamic link library. The patch may be a dynamic link library file and may behave just as a DLL. The process to overlay the instructions in the patch is the same as for known dynamic linking and no adaptation of the operating system is required.
An operating system that has the functionality to handle dynamic link libraries does not have to be modified to enable the invention. Therefore an embodiment of the invention maybe implemented on a number of operating systems which have the capacity for dynamic linking.
The fix up operation instruction may be a no operation instruction whereby the option of superimposing a prefix operation for the following operation is allowed. For platforms not requiring a prefix operation the no operation instruction will remain in place with minimal overhead. If a patch for such a system was loaded it would contain a no operation instruction to negate the effect. For platforms which would benefit from a prefix, a patch would contain that prefix and replace the no operation instruction without disruption to the following or preceding code.
Advantageously, when the platform is multiprocessor, the prefix operation is a lock operation to lock memory from other processors during a modify read write instruction. This allows a single object code application to be used for single processor platforms and for multiple processor platforms.
Another beneficial use of the embodiment is when the fix up location is a call subroutine instruction and the patch modifies the call subroutine instruction. For instance the subroutine may be optional for different platforms or may be a trace which is used on occasion during and after development of the application.
A further beneficial use of the embodiment is when the fix up location is an offset into a structure and the patch modifies the offset. Normally structure sizes must be maintained across DLL versions to preserve compatibility. If offsets are imported as dynamic values, then the offsets can change independently of the program.
Fix up locations may point to addresses for known dynamic linking as well as to operational code.
An operating system for resolving a program code module into a computer platform, said operating system: means for loading a module into memory; means for locating certain operation code within the module; means for selecting a patch for the operation code; and means for modifying the operation code with the patch.
The invention provides a program module for loading into a computer platform, said program module comprising a code segment and a fix up pointer; said pointer having a location value of an operational code field in the code segment and said pointer being associated with another module; whereby on being loaded to the computer platform the operation code is modified by patching the associated module.
Increasingly computer applications are using more operational memory than before. One of the factors contributing to this demand has been the move towards object oriented programming techniques which break an application into many separate and independent modules rather than a single contiguous piece of code. Since a module has some degree of independence it may be loaded into memory only when referenced by another module. When referenced, a module is loaded into memory and linked into the application. That is, references from the application to the module are hard coded so that the processor can seamlessly jump from the application to the module and back. One known module for loading and linking is a dynamic link library file (DLL). A jump or call instruction which is linked to a DLL file has an instruction field for the op code and an empty address field linked to the referenced DLL file. A dynamic link resolver locates the name of the DLL in an established module by looking up a table of the references in the header of the established module. The DLL file is loaded into a specific memory location and the resolver links or updates the address field of the instruction with an absolute or relative address of the specific memory location.
The invention uses the dynamic linking facility of the operating system to patch instruction sequences, rather than offsets or addresses of routines to be linked to. It patches instruction sequences using dynamic linking for different operating system and processor versions of a computer program. Either the application program or the operating system can provide a dynamic link library which rather than exporting entry point address, exports actual instruction sequences. Different versions of these dynamic link libraries are then made exporting different instruction sequences as up to 4 bytes of data as though these were entry point address of routines. These are then imported by the calling routine, and treated as actual instruction opcodes.